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(S4)Titie: VIRUS DETECTION IN CUENT-SERVER SYSTEM 

(57) Abstract 

The iterative detection and treatment of viruses using 
virus detection objects and virus treatment objects is dis- 
closed. Pursuant to a request for a virus scan, a virus de- 
tection object is produced by a server (400) and is transmit- 
ted to a client (300A, B) for execution. The client (300A. 
B) receives and executes the virus detection object, and the 
results are transmitted to tt» senrer (400). The server (400) 
uses die results to produce an additional virus detection ob- 
ject which is also transmitted to tiie client (300A. B) and 
executed so tiiat tiie results can be transmitted to the server 
(400). The iterative production and execution of virus de- 
tection objects Is continued until a determination is made as 
to whetiier tiie targeted file or data includes a virus. Upon 
a determination tiiat a targeted file or data includes a virus, 
a vaccine specifically tailoicd to tfic conditions presented at 
ttie client (300A, B) and fte type of virus detected is pro- 
duced, preferably in tiie form of a virus treatment object. 
The request for a virus scan can be directiy made or indi- 
rectiy by a triggering event One virus detection server (400) 
embodiment includes a vims information expert system tiial 
applies conditional data to picdetennined Imowledge about 
virus scanning to make detemiinations such as when to scan 
for vimses. A network diagnosis and treatment application 
includes a diagnostic data module, an expert system, and a 
maintenance requesting module. The expat system appUcs 
the diagnostic data to predetemilned knowledge about tiie di- 
agnosis and maintenance of a network to make determinations 
upon which maintenance requests are made. Preferably, tiie 
expert system includes a vims information expert system. 
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VIRUS DETECTION IN CLIENT-SERVER SYSTEM 

p^^f^fTR'^TTNT) OF THE INVENTION 

Fifild ftf Invention 
5 The present invention relates generally to the detection of viruses in 

computer files and more particularly to the detection and treatment of viruses using 
network resources, the iterative detection and treatment of viruses, and the 
maintenance of computer networics. 

10 Pftgrription o f thft Related Art 

Computer viruses continue to be problematic to computers and computer 
■ users.' Such viruses are typically found within computer programs, files, or code 
and can produce vmintended and sometimes damaging results. One type of virus is 
aportion of program code that produces copies of itself in othar programs, allows 

15 the programs to perform tiieir regular operations, and surreptitiously performs 
otiier, unintended actions. Otiier types of viruses include, witiiout limitation, the 
following: worms, logic bombs, time bombs, trojan horses, and any malicious 
program or code residing in executable programs, macros, applets, or elsewhere. 
While advances have been made m the detection of viruses, the proliferation of 

20 computers and the increasing mterconnection of, and communication betweai, 
computers have also increased the opportunities for the spread of existing viruses 
and tiie development of new computer viruses. Thus, the number and type of 
viruses to vMctk a computer or computer system is potentially exposed is ever 
changing: This is one reason tiiat die information used to detect viruses requires 

25 seemingly constant revision and augmentation in order to detect the various strams 
of viruses. 

There are various methods for detecting vuiises. One metfiod of detection 
is to compare known virus signatures to targeted files to determine wheflier the 
targeted files include a virus signature and, tiius, the corresponding virus. The 
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comparison data used for virus detection might include a set of such known virus 
signatures and, possibly, additional data for virus detection. Typically, the 
comparison data is mamtained in a computer storage medium for access and use in 
Ac detection of viruses. For example, for a personal computer flie comparison data 

5 might be stored on the computed hard disk. Periodically, conq)arison data i^dates 
are provided to detect new or different forms of viruses. The comparison data 
updates are typically provided on some source storage medium for transfer to the 
storage medium used to maintain the comparison data. For example, an iqjdate 
might be provided on a floppy disk so that a personal computer user can transfer 

10 the comparison data update from the floppy disk to the computer hard disk to 
complete the update. 

The comparison data is essentially discrete and static. That is, all of the 
information used for the detection of viruses generally remains constant unless it is 
updated or altered by the user or other relevant party or action. This can be 

IS problematic because the quality of information used to detect viruses is reliant 
upon some form of comparison data maintenance. Another problem with 
updatabie comparison data is that the comparison data can quickly lose its eflBcacy 
due to the existence of new and different viruses. Thus, while a periodic update 
might seem effective, there is no telling how many new and different viruses could 

20 be produced in the interim. Still another problem with comparison data updates is 
that a transfer of an entke replacement set of data, or at least a transfer of all the 
new virus detection data, is typically undertaken in order to complete the update. 
Whether an entire replacement or all of the new virus detection data is involved, a 
significant amount of data must be transferred for the update. More specifically, if 

25 a user updates her virus detection information using, for example, an update 
provided on a floppy disk, at least all of the new virus detection mformation is 
transferred from the floppy disk to the appropriate medium. 

Regardless of the update source, the problems of updatabie comparison data 
remain. Specifically, the user, administrator, or other relevant party is still 
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typically responsible for accessing and updating the comparison data, the 
comparison data can quickly and unpredictably lose its efficacy, and a significant 
amount of data must be transferred fiwm the source to the storage medium used for 
the comparison data. Indeed, the amount of data to be transferred may be more 
5 problematic where internet resources are the source ofthe comparison data update 
since a significant amount of computational resources would be used to complete 
the update. 

Another problem in flie detection of viruses is that conditions vary fix>m 
computer to computer. Thus, a first computer or medium could require a first type 

1 0 of scanning while another computer or medium, even one in the same network as 
the first, could require a second type of scanning. In these instances, virus scans 
can be overinclusive in that the scaraung for viruses that could not possibly reside 
at Ae computer, and can be underinclusive if an exhaustive scan for the types of 
viruses likely to reside at the computer, based upon the conditions presented at the 

15 computer, is not undertaken. To adequately perform a virus scan according to the 
conditions particular to a computer, a user or other relevant party typically must 
configure the scan. This can be problematic because of reliance upon party input 
Additionally, the conditions pertaining to a particular computer and the requisite 
type of scanning can change. 

20 With the increasing interconnection and commimication between 

computers, the requirements for maintaining computers residing on a computer 
network have also increased. Again, maintenance is typically undertaken directly 
by a person, such as the network administrator, using resources which are locally 
available to the network administrator. For example, in the treatment of computers 

25 on a local area network for viruses, an administrator could commonly configure the 
computers tp access locally available virus scanning resources. This maintenance 
scheme is problematic in its reliance upon updates, its faUure to adapt to changing 
conditions, and its Mure to make adequate use of resources external to the local 
area network. 
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Accordingly, there remains a need for virus detection that obviates some of 
the problems inherent m the updatable comparison data model. Additionally, there 
remains a need for more effective implementation of internet resources for virus 
detection and for easier and more effective computer networic maintenance, 
particularly, by way of example, with respect to virus detection and elimination. 



f^TTjyrMABYnFTHE] 

In accordance with the present invention a virus ddection server is 
provided for centralized access and iterative techniques are provided to effectively 

1 0 detect and treat viruses. 

In one aspect of the present invention, viruses are iteratively detected at a 
client computer. A substantial portion of the tools and information requked for the 
detection and treatment of viruses is provided in a centralized location such as a 
servCT, preferably an internet or world wide web server. This virus detection server 

15 operates in conjunction witii a client to determine whether viruses reside at tiie 
client A virus scan is initiated when a request is received or directed at tiie virus 
detection server. The request is direct or can be initiated by various triggering 
events, such as a programmed request from the client tiiat does not require ongoing 
user initiation such tiiat the scan is mitiated witiiout a request tiiat it apparent to the 

20 user. 

Once it is determined by tiie vmis detection server tiiat a valid virus 
detection request has been received, the virus detection server operates to 
iteratively detect and treat viruses associated witii tiie requester, typically tiie client 
The iterative production of virus detection objects allows objects to be specifically 
25 tailored according to previously determined conditions and/or conditions 

discovered as a result of tiie execution of previously produced virus detection 
objects. Specifically, a virus detection object is produced by tiie virus detection 
server and is transmitted to tiie client The virus detection object mcludes an 
executable program which tiie client includes a corresponding executing engine. 
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Thus, when the cUent receives the virus detection object, it executes the object and 
produces a result that is transmitted back to the virus detection server. The results 
of the execution of the virus detection object are transmitted to the virus detection 
server so that the server can produce additional virus detection objects based iq?on 

5 tiic results of the ratecution of the previous virus detection object or objects. 

According to anolher aspect of the present invention, the virus detection 
server produces a vaccine specific to the conditions presented at tiie client, 
mcluding the specific type of virus tiiat was detected. The vuiis detection server 
receives the results produced by the execution of one or more virus detection 

10 objects and uses tiie results to tailor tiie vaccme. For example, the result may 
indicate that a specific virus is present in a specific type of file on a specific 
platform, and the vaccine is tidlored accordingly. The vaccine comprises one or 
more virus treatment object which include an executable program and/or a data set 
The virus treatment objects are sent to and executed at tiie client to treat the 

IS vuuses. 

According to stiU anotiier aspect of the present invention, a system of 
computers such as tiiose residmg on a local area network can be effectively 
screened for viruses witiiout requiring constant maintenance on the part of a system 
administrator. Specifically, events that regularly occur can be used to tiigger a 

20 request for virus scanning by the virus detection server. 

An embodiment of tiie vmis detection server includes various modules for 
tiie iterative detection and treatment of computer viruses. An iterative virus 
detection module includes a scanning module, a virus pattern module, a virus rules 
module, a cleaning module, a cleaning pattern module, an access managing module 

25 and an access data module. The scanning module includes a plurality of routines 
for detecting viruses which are provided such tiiat tiiey can be separately accessed. 
Similarly, tiie virus pattern module and tiie virus rules module respectively include 
groups of virus signatures and groups of rules tiiat can be separately accessed. The 
iterative virus detection module operates in conjunction with tiie scaniung module. 
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the virus pattern module, and the virus rules module to produce virus detection 
objects that are specifically provided for the detection of viruses based upon the 
conditions presented at the client 

The cleaning module includes routines for treatmg files that are determined 

5 to include a virus. A plurality of routines that can be separately accessed are 

provided in the cleaning module, as are a plurality of virus detection patterns in the 
virus detection module. The iterative virus detection module operates in 
conjunction with the cleaning module and the cleaning pattern module to produce 
virus treatment objects that are tailored for the treatment of the particular virus or 

10 viruses that are detected at the client in the prevailing conditions presented at the 
client 

The access managing module includes routines for determining whether a 
request for virus scanning has been provided and for validating the request upon 
such a determination. The access managing module operates in conjunction with 

15 tfie access data module, which includes information pertaining to potential users, in 
order to acknowledge and validate virus scanning requests. 

According to still another aspect of the present invention, another 
embodiment of a vmis detection server includes a virus information expert system. 
Conditional data pertainmg to the conditions presented at computers, media, or 

20 other scanning targets is gathered and mamtained. The conditional data is applied 
to predetermined knowledge to make determinations used in conductmg a virus 
scan. An embodiment of the expert system includes an inference engine and a 
virus knowledge module. The inference engme accesses the conditional data and 
applies the conditional data to rules and information provided in the virus 

25 knowledge module to make determinations about the type of virus scanning to be 
performed. .Exemplary determinations include the determination of whether a scan 
is appropriate, the assessment of conditions pertaming to the request for scanning, 
and tiie type of scanning and cleaning routines to be implemented. 
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According to still another aspect of the present invention, a network 
diagnosis and maintenance application is provided. The network diagnosis and 
maintenance application gathers information about a network and maintains 
diagnostic data corresponding to the gathered information. Determinations about 

5 network conditions are made by applying the diagnostic data to predetermined 
knowledge, and request for network maintenance are requested based up<m the 
detemiinations. An embodiment oftiie diagnosis and maintenance arolication 
includes a diagnostic data module, a maintenance requesting module, and at least 
one expert system witii an inference engine and predetermined knowledge. The 

1 0 diagnostic data module provides the diagnostic data, which is accessed by the 
expert system and tiien applied to rules pertaining to its field of expertise to make 
determinations about tiie network. The determinations are then used by the 
maintenance requesting module as a basis for requesting network maintenance. An 
exemplary expert system is a virus information expert system including an 

15 inference engine and a virus knowledge module. The determinations made by tiie 
virus information expert system are communicated to tiie maintenance requesting 
module, vMch can use tiie determinations to request virus scanning and treatment 
by a virus detection server. 

20 RRTFF nFSCRT PTTnN OF THR DRAWINGS 

These and otiier more detailed and specific features of tiie present invention 
are more fully disclosed in tiie following specification, reference being had to tiie 
accompanying drawings, in which: 

FIG. 1 is a schematic illustrating exemplary interconnections between a 
25 client and a virus detection server in accordance witii tiie present invention. 

FIG. 2 is a flow diagram illustrating a method of iterative virus detection in 
accordance with the present invention. 

fig! 3 is a block diagram illustrating an embodiment of a client in 
accordance with the present invention. 
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FIG. 4 A is a block diagram illustrating an embodiment of a virus detection 
server in accordance with the present invention. 

FIG. 4B is a block diagram illustrating an embodiment of an iterative virus 

detection module in accordance with the present invention. 
5 FIG. 4C is an exemplary data table illustrating indexed mformation 

corresponding to viruses. 

FIG. 4D is an exemplary data table illustrating virus signature component 
strings used with a virus detection technique in accordance with the present 
invention. 

10 FIG. 5 is an event diagram illustratmg a method of virus detection using a 

virus detection server in accordance with the present invention. 

FIG. 6A is a block diagram illustrating another embodiment of an iterative 
virus detection module in accordance with the present invention. 

FIG. 6B is a block diagram illustrating an embodiment of a virus 
1 5 information expert system in accordance with tiie present mvention. 

FIG. 7 is a schematic illustratmg an exemplary network communication 
system in accordance with the present invention. 

FIG. 8 A is a block diagram illustrating an embodiment of an administrative 
server in accordance with the present invention. 
20 FIG. 8B is a block diagram illustrating an embodiment of a network 

diagnosis and treatment application in accordance witii the present invention. 

PFJATT FD PFSCRTPTTON OF THE TNVRNTIQN 

Referring now to the schematic diagram of Fig. I, the virus detection server 
25 and The method of virus detection of tiie present invention preferably operate on a 
system wherein a client-server relationship can be established between the virus 
detection server 400 and any one of a plurality of clients 300. In the system 100 
illustrated in Fig. 1, the virus detection server 400 resides on a wide area network 
(WAN) such as the network typically referred to as tiie Internet or World Wide 
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Web. Various exemplary interconnections are shown between clients 300 and a 
virus detection server 400. In one example, the client 300a is shown coupled via 
line 10 to the WAN to allow Communication between the client 300a and the virus 
detection server 400. In this example, particularly where the WAN is the Internet, 

5 access can be provided by an internet access provider or an internet service 

provider and the client 300 includes a modem coupled to a telqjhone line to link to 
the service or access provider. In another example, the client 300b is part of a local 
, area network (LAN) and communication between the cUent 300b and the virus 
detection server 400 can be fecilitated by a connection 20 estabHshed through a 

10 LAN server 350. Although access can also be through an access or service 

provider, the connection 20 can be by other conventional means such as a leased 
line. 

Although the preferred embodiment of the present invention contemplates 
ftat the virus detection server. 400 is an Internet server, the ordinarily skiUed 

15 artisan will recognize the various alternatives for establishing a client-server 
connection between the virus detection server 400 and a cUent 300, such as 
interconnection within a local area network of computers or over any internetwork 
coimection of computers. 

The virus detection server 400 uses a conventional operating system such as 

20 UNIX or Windows NT and implements conventional internet communication 
protocols such as the transmission control protocol/internet protocol (TCP/IP) 
suite. Additionally, the communication protocols can include various conventional 
q)pUcation layer protocols such as die file transfer protoc9l (FTP) and/or the 
Hypertext Transfer Protocol (HTTP) for the transfer of files or otiier information 

25 between die client and the vmis detection server 400. 

After communication between the virus detection server 400 and die client 
300 are conventionaUy estabUshed, Has virus detection server 400 operates to 
determine whetiier a virus is associated with a cUent 300 and. where a virus is 
detected, to provide appropriate treatinent for the type of virus tiiat is detected. 
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Briefly, the virus detection server 400 operates in conjunction with the client 300 
to determine whether viruses reside at the client by iteratively producing virus 
detection objects at the server, transmitting the virus detection objects to the client, 
executing the virus detection objects at the cUent, and using the results of the 

5 execution of tiie virus detection objects, particularly tiie current virus detection 
object, to produce subsequent virus detection objects and ultimately to detect the 
presence of a virus. AdditionaUy, a vaccine comprising one or more virus 
treatment objects is tailored to treat the conditions as deteraiined by the iterative 
production and execution of the virus detection objects. 

10 Referring now to Fig. 2 along with Fig. 1, a flow diagram Ulustrating a 

method of iterative vims detection in accordance with the present invention is 
described. Figs. 1 and 2 provide a general understanding of iterative virus 
detection. An embodiment of a virus detection server 400 and method for 
detecting viruses are described in further detail witii reference to Figs. 3-5 below. 

15 In an initial step 205, a request for a virus scan is received, typically from a 

source external to tiie virus detection server 400 such as a cUent to be scanned. 
After receipt of tiie request, in step 210 it is determined by tiie virus detection 
server 400 Vvhetiier a scan is to be performed. Preferably, a validation of tiie virus 
scan request is performed pursuant to tiie deternunation of whetiier a scan is to be 

20 performed. Continuing witii a typical example, tiie request can be provided by tiie 
client 300 in tiie fonn a request directed to tiie virus detection server 400, 
whereupon tiie virus detection server 400 can validate tiie request before 
proceeding witii tiie determination of whetiier a virus is associated witii flie client 
300. Preferably, request validation is made by reference to information stored at or 

25 accessible to tiie virus detection server 400. 

The conventional protocols of tiie network, such as tiie WAN in tiie 
embodiment of Fig. 1, are used to route tiie request from tiie client 300 to tiie virus 
detection server. For example, tiie request can implement a uniform resource 
locator (URL) address corresponding to tiie virus detection server 400. Once 
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contact is initiated, conventional protocols, such as the HTTP and FTP referenced 
above, are used to transfer information between the virus detection server 400 and 
the client 300. Various alternatives for the establishment of a connection between 
the client 300 and the virus detection server 400 can be provided. The request for a 

5 virus scan can also be routed through a separate server that handles initial requests 
and, possibly, validates them before passing the cUent 300 to the virus detection 
server 400 (and thus the request and ttie validation would be received together by 
, the virus detection server 400). Additionally, altiiough a connection witii and 
resultant virus detection and treatment for a single client is generaUy described, a 

10 single virus.scan request that is received by the virus detection server 400 can 

cause tiie server 400 to detect and treat viruses on a plurality of clients 300, such as 
all of tiie clients 300b residing on a given local area network. 

In addition to direct client 300 prompting, tiie request for a virus detection 
scan can be produced as a result of a triggering event. Thus, a virus detection scan 

15 can be initiated witiiout user input, or knowledge in certain instances. Aswitiia 
user prompted request, tiie triggering event causes a request for a virus scan to be 
Transmitted to tiie virus detection server 400, which receives tiie request and 
validates it prior to tiie progression of tiie determination of whetiier a virus is 
associated witii tiie cUent 300. An agent program, resident at tiie client 300 or 

20 elsewhere, can be used to produce tiie request for a virus scan in reaction to tiie 
triggering event. In tiiat instance, tiie agent program initiates tiie request and 
resultant connection between tiie client 300 and tiie server 400. The request for a 
virus scan, validation of tiie request, tiggering events, and agent program are 
described in fortiier detail witii reference to tiie event diagram of Fig. 5, described 

25 below. 

After it is determined 210 tiiat a scan is to be performed, a plurality of virus 
detection objects are produced by tiie virus detection server 400 and transmitted to 
tiie client 300 until it is determined whetiier a virus is associated witii tiie cUent 
300. In step 215, an initial virus detection object is produced by tiie virus detection 
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server 400 and transmitted to the client 300. The virus detection objects include a 
program or code that the client 300 is capable of executing as well as data. 
Alternatively, selected virus detection objects might consist of executable code 
only, or data only. Conventional networic transmission protocols are used to 
5 transmit the virus detection object from the server 400 to the cUent 300. After 
receipt of the virus detection object, in step 220 the virus detection object b 
executed by the client 300 and in step 225 the results of virus detection object 
, execution are transmitted to the virus detection server 400 which receives the 
results and in step 230 produces an additional virus detection based upon the result 
10 of the execution of the first virus detection object. The extent of the results 
transmitted to the server 400 can vary. For example, the results can dictate the 
production of the additional virus detection object directly, can be raw results such 
as data that requires interpretation by the server 400 in order to produce the 
additional object, or can be intermediate to the two extremes. Additionally, the 
15 extent of Ihe results can be structured according to the desired allocation of 

resources between the client 300 and the virus detection server 400. As with the 
initial virus detection object, the additional virus detection object is transmitted to 
the client 300 so that, as shown in step 235, it can be executed, and then results are 
transmitted to the virus detection server 400. The production of virus detection 
20 objects continues untU a determination is made in step 245 as to whether additional 
scanning is ho longer required. Preferably, the determination 245 is made by the 
vims detection server 400 based upon the last received result, but it is understood 
that the client 300 can make the determination and include the determination in tiie 
result that is transmitted to the client. If in step 245 it is determined that additional 
25 scanning is required, then the method returns to step 230 wherem an additional 
virus detection object is produced. 

By proceeding with the determination of whether a virus is associated with 
the client 300 in iterative fashion, the information transmitted from the server 400 
to the client 300 is tailored to include only that information necessary for the 
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detection of viruses at the cUent 300. Specifically, the information can be 
limited to detect the type of viruses that are likely to reside at the cUent based upon 
the conditions presented at the client (such as platform or file type), or could be 
limited to the ^pe of virus detection request made by the client. This significantly 
5 reduces the overall amount of information necessary for the detection of viruses 
and, likewise, reduces the amount of information to be transmitted fix)m the server 
400 to the client 300. Additionally, the client 300 has access to state of the art 
virus detection information since the information used by the virus detection server 
400 can be maintained without requiring cUent 300 action. Moreover, there is no 
10 need for the client 300 to engage in a comprehensive downloadmg of an entire 
virus detection comparison data update. Finally, computational overhead on tfie 
client side is minimized since the virus detection objects and any executable 
portions thereof are tailored to the conditions presented at the client 300. 

If, as a result of the iterative production, transmission and execution of 
15 virus detection objects, it is determined in step 250 tiiat a virus is not associated 
witii the client 300, tiien the client 300 or otiier relevant party is appropriately 
notified in step 265 by tiie virus detection server 400. However, if a virus is 
detected, tfien in step 255 flie virus detection server 400 produces and transmits to 
tiie client 300 a vaccine tailored for Has treatment of tiie type of virus tiiat was 
20 detected. Finally, in step 260, the vaccine is executed by tiie client By tailoring 
ti»e vaccine according to tiie results of tiie execution of the virus detection objects, 
tiie amount of information transmitted to and tiie computational resources 
consumed at tiie client 300 are minimized while an up to date treatinent protocol is 
implemented. Preferably, tiie vaccine comprises at least one virus treatment object 
25 produced by tiie virus detection server 400 based upon tiie results of tiie iterative 
virus detection object execution. Additionally, as witii tiie virus detection objects, 
a plurality of virus tieatinent olqects can be produced to iteratively treat tiie client 
300. Specifically, a first vLrus treatment object can be transmitted to flie client 300 
for execution to ascertain additional information, such as system information or 
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infonnation input by the user, for the treatment of the virus. Then, a second virus 
treatment object is produced based upon the results of the execution of the first 
virus treatment object, and is transmitted to the client 300 for execution. 

Referring now to the block diagram of Fig. 3, an embodiment of a client 
300 used in accordance with the present invaition is shown. The client 300 
includes a central processing unit (CPU) 312, a memory 314, a data storage device 
3 16 such as a hard disk, a keyboard 3 1 8, a monitor 320, a mouse 322, a network 
interface 324 and a communications unit 326. The CPU 3 12 is coupled to the 
memory 3 1 4, data storage device 3 1 6, the keyboard 3 1 8, the monitor 320, the 
mouse 322, the network interface 324 and the communications unit 326 via a 
system bus 3 1 0 in a conventional architecture. The CPU 312 is preferably a 
microprocessor such as a Pentium as provided by Intel of Santa Clara, California. 
AdditionaUy, the monitor 320, keyboard 318, and mouse 322 are conventional and 
configured to provide and receive data as is well known. The communications unit 
326 is a conventional device configured to allow communication between the client 
300 and other computers. Preferably, the communications unit 326 is a 
conventional modem connected to a Une 10 such as a conventional telephone line. 
The network interfece 324 is also a conventional device configured to allow 
communication between the cUent 300 and other computers. Preferably, the 
network interface 324 is a conventional network adapter card including a 
transceiver that is coupled to a networic transmission medium 25 such as a coaxial, 
twisted pair, fiber optic, or other line. As shown in Fig. 1, communication between 
tiie client 300 and the virus detection server 400 can be facilitated through the 
network interface 324 or, alternatively, the communications unit 326. 

In conventional fashion, the CPU 312 can be directed by instructions 
provided in memory 314 to perform desired functions. Additionally, input can be 
provided by tiie mouse 322 and keyboard 318 and output to tiie monitor 320 in 
conventional fashion, and communication between tiie computer and otiier devices 
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can be facilitated through the communications unit 326 and/or the networlc 
inter&ce 324 in conventional fashion. 

The memory 314 is shown to include an operating system 328, a browser 
330, and a virus detection shell 332. The operating system 328 is preferably a 

5 conventional one for a personal computer such as Windows95 or WindowsNT as 
provided by Microsoft, Inc. of Redmond, Washmgton. The memory 314 may also 
include a?>plication programs such as word processing and spreadsheet programs 
configured to function using the operating system 328. Tte browser 330 is 
preferably a software program for accessing and commimicating with other 

10 computers. In the preferred embodiment, the browser 330 is Internet Explorer as 
provided by Microsoft, Inc. The client 300 also includes an engine capable of 
executing the programs provided in the virus detection objects produced by tiie 
virus detection server 400. Although it is understood that tiie engme could be 
provided otherwise with the client 300, in accordance witii a preferred embodiment 

15 of the present invention, the engine is provided in conjunction witii tiie browser 
330, and thus die browser 330 is considaed to be "enabled" for die execution of 
the programs provided in the virus detection objects. In die preferred embodiment. 
ActiveX programming tools, also as provided by Microsoft, Inc., are used in die 
production of the virus detection objects used in die iterative detection of viruses. 

20 ActiveX programming tools are means for producing objects, called "controls" in 
ActiveX terminology, which objects can include executable code that can reside at 
a server and can be accessed by a client. The controls can also be tiansmitted to 
tiie client, and, provided tiiat the client includes the means for doing so, executed 
by die cUent. In the preferred embodiment the browser 330 is ActiveX enabled and 

25 die virus detection objects are ActiveX controls. Various alternatives can be used 
for die browser 330 and to provide die executable portions of tiie virus detection 
objects. For example, die browser 330 could be die Netscape Navigator as 
provided by Netscape. Inc. AdditionaUy, die virus detection (and treatment) 
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objects can, for example, be applets such as Java applets. Java programming tools 
are provided by Sun Microsystems, Inc. 

The CPU 312, at the direction of instructions received ftom memory 314, 
operates to receive virus detection and treatment objects, execute the objects, and 
5 transmit results to the virus detection server 400 for the client 300. Preferably, 
viruses are detected and eliminated without requiring a specific application 
program. Thus, provided that the client 300 can access the virus detection server 
400 to make a request, such as through communications unit 326; make a request 
and communicate with the virus detection server 400, such as through instructions 
1 0 provided in conjunction with the browser 330; and execute objects produced by the 
virus detection server 400, such as via an enabled browser 330, viruses can be 
detected and treated at the client 300 using the virus detection server 400. 

Since viruses can be detected and treated at the client 300 using the virus 
detection server 400 using the enabled browser 330 (or other means to execute the 
15 virus detection objects), viruses can be detected and treated without the virus 
detection shell 332. 

However, although the virus detection shell 332 is optional, it can 
alternatively be provided in memory 314 for various purposes in accordance with 
the present invention. First, the shell 332, in Ueu of the browser 330 can include 
20 the means necessary to execute virus detection objects. Additionally, the virus 
detection shell 332 can provide information used in conjunction with the detection 
and treatment of viruses. For example, the virus detection shell 332 can include 
account information or detailed virus detection configuration settings that can be 
provided to the virus detection server 400 without requiring iterations of object 
25 production and execution. Specifically, the virus detection shell 332 could include 
settings for defining the triggering event for requesting a virus scan or could 
specify the data storage devices, directories, files, file types, or any other 
information that could help identify or narrow the type of scanning that is desured 
by the user. 
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Refeiring now to the block diagram of Fig. 4A, an embodiment of a virus 
detection server 400 in accordance with the present invention is shown. The virus 
detection server 400 includes a CPU 412, memory 414, a data storage device 416 
such as a hard disk, I/O ports 418 and a network interface 420. The CPU 412 is 

5 conventional such as a Pentium Pro as provided by Intel Corporation, Santa Clara, 
California. The memory 414 is preferably conventional RAM but may also 
include conventional ROM. AdditionaUy, the memory 414 is preferably 
configured to include routines for the iterative detection of viruses. The 
configurations are described in further detaU with reference to the iterative virus 

10 detection module 450b of Fig. 4B. The data storage device 416, VO ports 418 and 
network interface 420 are conventional and respectively facilitate long term data 
storage, input and output from the server, and communication with other 
computers. The CPU 412, memory 414, data storage device 416, I/O ports 418 and 
corresponding devices, and network interface 420 are coupled to a bus 410 in 

15 conventional feshion. The CPU 412, under the guidance and control provided by 
instructions received from memory 414, provides sipials for sending and receiving 
data through the network interface 420 and transmission line 430 to facilitate 
communication with other devices such as a client 300. As described with 
reference to Fig. 1, conventional network communication protocols such as the 

20 TCP/IP protocol smte are used for such communication. Additionally, tiie 
instructions received from memory 414 allow tiie virus detection server 400 to 
produce vims detection and treatment objects and transmit the virus detection and 
treatment objects to anotiier computer such as tiie described client 300. The 
instructions.also facilitate tiie receipt of tiie results of tiie execution of virus 

25 detection and treatment objects and to use those results to produce additional 
objects. 

Referring now to Fig. 4B, an embodiment of an iterative virus detection 
module ("IVDM") 450b in accordance witii tiie present invention is shown to 
include a scanning module 454, a virus pattern module 456, a virus rules module 
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458, a cleaning module 460, a cleaning pattern module 462, an access managing 
module 464, and an access data module 466. The iterative virus detection module 
450b, and its referenced modules, includes routines for receiving virus detection 
requests, validating requests, producing virus detection and treatment objects, 
5 receiving the results of the execution of the vims detection and treatment objects, 
and using Ae results to produce additional vims detection and treatment objects to 
ultimately detect viruses and treat them. The iterative virus detection module 450b 
is ^ically implemented in software, but can also be implemented in hardware or 
firmware. 

10 The access managing module 464 includes routines for determmir^ the 

validity of virus scanning requests which are received by the \drus detection server 
400. The access data module 466 is in operative communication witii tiie access 
managing module 464 and includes information tiiat is used in access validation. 
For example, information about users including a user identification code and an 

15 account validity indicator can be stored m tiie access data module 466. Thus, when 
a request for a virus scan is made, tiie IVDM 450b, in conjunction witii tiie access 
managing module 464, identifies flie requester and uses tiie data in tiie access data 
module 466 to determine whetiier tiie user identification code is listed and whetiier 
the account is valid. Various alternatives can he implemented for user 

20 identification and validation, such as one where a user initiates a request and is 
prompted for an identification code and a password to validate tiie requester's 
access of tiie virus detection server 400 for tiie detection and treatment of viruses. 
The access managing module 464 is also arranged to set up an account for a new 
user and tiierefore is configured to acquire tiie necessary information. 

25 After it is determined tiiat a valid request for scanning has been provided, 

virus detection objects are iteratively produced and transmitted to tiie requester, 
such as a client 300, in order to detect a virus. The scanning module 454 includes 
various routines tiiat can be used in tiie detection of viruses. Preferably, tiie 
routines are provided for separate access so tiiat vims detection objects can be 
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tailored to include selected scanning routines. For example, separate routines for 
the detection of viruses that could reside in systems using particular platforms and 
operating systems, in particular file types, and in particular locations are provided 
for separate access in the scanning module 454. SpecificaUy, routines for the 

5 detection of viruses that typically reside on one platform are provided such that 
they can be accessed separate &om routines for the detection of viruses tiiat 
typically reside on another platfomi. Similariy, routines for tiie detection of 
viruses that reside in "executable" files (such as tiiose fliat have tiie file extension 
.exe) are provided such that they can be accessed separate fiom routines used for 

10 the detection of macro viruses (such as tiiose tiiat implement tiie WordBasic 
progiammmg language, typically reside in application data files, and include 
extensions such as .doc or Jot). Thus, a virus detection routine tiiat examines a 
file to determine vdietiier it includes a virus signature can be separated &om a virus 
detection routine tiiat use a set of rules, such as combinations of suspect 

15 instructions, to determine whetiiervuruses are present in files. Otiier types of virus 
detection routines can be provided in tiie scanning module 454, such as tiiose used 
in the detection of viruses in electronic mail messages. 

Preferably, the routines provided in tiie scaxming module are configured to 
use ttie particular programmmg tools used by tiie vurus detection server 400 to 

20 detect viruses at tiie client 300. Thus, tiie routines are capable of being executed by 
tiie client 300. Alternatively, tiie routines provided in tiie scanning module can be 
converted fix)m a first executable type to an executable type supported by tiie client 
300. 

In the preferred embodiment, various routines are provided for separate 
25 access in the scanning module 454. For example, routines corresponding to tiie 
detection of virus signatures in various types of files are provided. Information 
about each routine is provided in association witii tfie routine to fecilitate coherent 
separate access. For example, for virus signature detection routines, information 
such as tiiat conesponding to platform and file type are provided in association 
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with each routine. Thus, the IVDM 450b, in conjunction with the scanning module 
454, can efficiently determine which routine requires access when necessary. 
Typically, the decision whether to use a particular routine will depend upon the 
conditions at the client 300. The conditions can be predetermined or can be 
5 acquired by the virus detection server 300 through interaction corresponding to 

scope and risk assessment, described further below with reference to Fig. 5. 
Conventional indexmg and sorting techniques can be used to tag the various virus 
scanning routines provided m the scanning module 454 and, accorduigly, to 
facilitate separate access. 

10 Similar to the scanning module 454, the virus pattern module 456 and virus 

rules module 458 respectively include virus signatures and rules that can be used in 
the detection of viruses. As with the routines described in connection with the 
scannmg module 454, the patterns and rules are provided to facilitate separate 
access. Thus, for example, the file signatures m the virus pattern module 456 

15 corresponding to one type of file can be separated from the virus signatures 

corresponding to a second file type. Similarly, the rules in the virus rules module 
458 corresponding to one detection criteria can be separated from the virus rules 
that apply to a second detection criteria. As with the routines in the scannmg 
module 454, conventional indexing and sorting techniques can be used to provide 

20 separate access to the patterns and rules. Of course, a plurality of signatures or 
rules could apply to a particular indexing field. For example, several signatures 
would correspond to tiie indexing field .exe and thus would be included, subject to 
other indexing limitations, in the virus signatures corresponding to such scanning 
conditions. 

25 In addition to providing routines and corresponding signatures or rules tiiat 

separately accessible and tiius amenable to tailoring according to the assessed 
scope and risk presented at tiie client 300. tiie virus scanning stage is provided such 
that scanning can be undertaken in iterations. 



-20- 



wo 98/41919 



PCT/US98/03796 



For example, in a preferred technique a plurality of files, such as all of 
those residing on a cUent 300 hard disk 3 16, are initially scanned to determine 
whether they include a first portion of a virus signature (or a plurality of virus 
signature portions). The result of the initial scan will indicate those files, if any, 
5 that include the portion. Then, a second scan is undertaken based vpon the result 
of the first scan. Specifically, those files that include the first portion are scanned 
to determine whether they also include a second virus portion. Those files that 
include the first portion and the second portion are candidates for inclusion of the 
entire virus signature and thus the virus. With this technique, the amount of data 
10 used as comparison data for the initial scan is minimized since only a portion of the 
virus signature is required for the scan. Additionally, since the number of files to 
be scanned is gradually narrowed, the computational resources used in the scan, 
particularly at the client 300, are lowered. 

An exemplary indexing of virus signatures and the preferred signature 
15 scanning technique are now described with reference to Figs. 4c-4d. Referring to 
Fig. 4c, an exemplary data table 475 is shown to include columns for platform, 
virus type, and virus identification. In the exemplary table 475, each row includes 
information about a particular vuiis. The information can be used to determine 
whether a scanning routine corresponding to the particular virus will implemented. 
20 Of course, various scanning routines will correspond to groups of viruses with 
common characteristics. The data table 475 provides an example of how various 
virus information is indexed. Various additional or alternative criteria for 
determining which scanning and treatment routines to use can be provided. 

Preferably, information such as that provided in the exemplary data table 
25 475 is provided in memory 414 for access by the IVDM 450a in the selection of 
virus scanning and treatment routines and, more specifically, m the production of 
virus detection and treatment objects. Assuming that, either by iterative object 
determination in die scope and risk assessment stages, or by user input, or by 
predetermined settings, that only files type viruses corresponding to a given 
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platform I are targeted for scanning, the target would only be scanned for viruses 
such as viruses A, C, and E. The scanning routines are provided in the scanning 
module 454 and are indexed for access. Additionally, virus signatures are provided 
in the virus pattwn module 456 and are indeced for access. Thus, using 

5 information such as that shown in the data table columns, the appropriate scanning 
routines for detecting file ^ viruses and virus signatures corresponding to 
viruses A, C and E are accessed. Although a virus detection object including full 
signatures corresponding to these three selected viruses could be provided in 
accordance Mwith the present invention, a technique is provided vMch allows a 

10 further reduction in the amount of information required for transmission to the 
client 300 in order to detect viruses. 

Referring now to Fig. 4d, another exemplary data table 480 includes 
columns for the virus identifier and a column generally indicating segregated virus 
component string data. As shown, the virus signature for each identified virus is 

15 broken into portions that can be used in the detection of viruses. In one 

embodiment, the portions comprise one byte strings, but it is understood that the 
length of the string can differ. Specifically, for virus A, strings Al, A2, and A3 are 
shown, for virus B, strings Bl, B2 and B3 are shown, and for virus C, strings CI, 
C2 and C3 are shown. The table 480 is provided by way of example. It is 

20 understood that many additional portions or strings could be provided for each 
virus. It is also understood that data for many more viruses could be provided. 

An iterative, progressive virus scan can be undertaken using virus signature 
portion data such as that in the data table 480. There are two ways that tiiis type of 
scanning can be implemented, referred to as the first and second types below. 

25 In the first type of detection, detection is undertaken by iteratively scanning 

all ta^eted files for die relevant string portions to progressively narrow the number 
of viruses fiat could reside in tiie targeted files. The virus portions do not have to 
be adjacent strings in tiie signature. Once tiie number of viruses tiiat is potentially 
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present is sufficientiy narrowed, a foil virus signature corresponding to each 
possibly present vims is provided so that the appropriate files can be scanned. 

In the second type of detection, the scan itself is conducted using the plural 
virus signature portions. Preferably, the virus portions are adjacent strings in the 
5 signature, and the virus detectionobjects are arranged to detect presence and 

location within targeted files. . 

Specifically referring to the first type of detection, an initial virus detection 
object includes a routine for scanning aU of the targeted files to determine wheAer 
they include the initial portions or strings Al. Bl, and CI. The virus detection is 

10 produced by the segregated and indexed data and transmitted to the client 300. The 
client then executes the virus detection object to produce a result. The result 
mdudes an indication as to whether the portions or strings are included in the 
targeted files and, if so, an identification of which files included which strings. 
Assuming that 100 files were targeted, that no targeted file included string CI, and 

15 5 of the targeted files included either string Al or Bl (or both), the result of the 
execution of the vmis detection object would indicate as such. Preferably, the 
identification of the 5 files remains at the cUent, and the result transmitted to the 
virus detection server 400 is that strings Al and Bl were found (and thus no files 
with string CI). The virus detection server 400 then uses this result to produce a 

20 second virus detection object. In this instance, the second virus detection object 
would include only strings A2 and B2, since virus C was eliminated firom 
consideration. The second virus detection object is then executed at tiie client 
Specifically, the client scans the 5 identified files to determine whether they 
include tiie combination of Al & A2 or Bl & B2. The results of the previous 

25 execution (fofmdAl,Bl, etc.) could be used such tiwt only the second strings 
would need to be scanned for, or, alternatively, tiie files could be scanned for botii 
strings. The execution of tiiis virus detection object could tiius discount viruses A 
and B from consideration. Assuming tiiat certain files were found to mclude botii 
Bl & B2 but no file included botii Al and A2, a fiiU virus signature corresponding 
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to virus B could be provided in the next virus detection object so that the targeted 
file or files could be scanned to determine whether the virus resides at the client 
300. It is undCTStood that using this technique the number of iterations, the number 
of viruses which remain possibly present, and the number of files ultimately 

5 scanned can vary. Regardless, by using a limited amount of comparison data, a 
screening can be undertaken such that when fiiU vuus signatures are finally 
transmitted to the client 300, their number and the corresponding amount of data to 
be transmitted are effectively minimized. 

In the second type of detection, the strings comprise adjacent portions of 

10 the viruses and thus the iterative scan can also detect the virus (rather than just 
limit the amount of viruses that could be present followed by a full virus signature 
transmissiofi). In the second type of detection, therefore, additional information 
about the files including strings and the location of the strings is provided. 
Specifically, in the second type of detection, if the initial vims detection object 

15 indicates that 5 targeted files include Al or Bl, then an identification of which files 
include which string is retained, as well as a maricer so that a determination could 
be made as to whether the adjacent string A2 or B2 respectively followed string Al 
or Bl in a targeted file. In this fashion, the number of viruses vAach are potentially 
present can be rapidly minimized and efforts are not duplicated since the fiill 

20 signature does not have to be transmitted after transmission of vmis portions. 

Although a preferred technique for iteratively detecting viruses and thus 
minimizing the amount of data to be transmitted to the client is described, other 
techniques can be provided. Some examples of virus detection techniques that can 
be modularized or subdivided to provide iterative detection are tiiose used in tiie 

25 detection of unknown viruses in macros and those used in electronic mail scaraung. 
These examples are also discussed witii reference to tiie vuns scanning stage in tiie 

event diagram of Fig. 5. 

Again the routines, patterns and rules for iterative virus scannmg are 
respectively provided for separate access in tiie scanning module 454, virus pattern 
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module 456 and vims rules module 458. Still referring to Fig. 4B, the IVDM 
450b, in conjunction with the virus scanning module 454, the virus pattern module 
456 and the virus rules module 458, iteratively produce virus detection objects 
based upon the results of tfie execution of previous virus detection objects. Since 

5 the routines in the virus scamiing module 454 and the rules and patterns in their 
respective modules 458, 456 are provided such that they can be separated, the 
rVDM 450b can produce virus detection objects that include a limited amount of 
data that is specifically directed at the type of conditions presented at, for example, 
a client 300 to be scanned for viruses. For example, where it is indicated by 

10 previous iterations (or separately provided input) that only executable files that 
have not been compressed and reside la a particular directory are to be scanned, the 
IVDM 450b accesses the routines in the virus scanning module 454 that are used 
for the detection of viruses in executable files, accesses the virus signatures the 
could be presented in executable files in the virus pattern module 456 and produces 

1 5 a virus detection object using the information. The appropriate virus detection 
routines from the scanning module 454 and information fix)m the virus pattern 
module 456 and/or the virus rules module 458 are used to produce the virus 
detection object As described previously, the object typically implements a 
conventional programming language sudi as that provided in ActiveX controls or 

20 Java applets. 

Once each virus detection object is produced, it can be transmitted from the 
virus detection server 400 to the client 300 using conventional network 
transmission protocols. The computer client 300 executes the virus detection 
object and transmits the results of the execution for receipt by tiie virus detection 

25 server 400. The IVDM 450b, in conjunction with tiie virus scanning module 454, 
uses tiie execution results of the virus detection object to determine whetiier 
additional virus detection objects are required, and, where no additional virus 
detection objects are required, whetiier a virus was detected. In a preferred metiiod 
of operation, tiie iterative production of virus detection objects is divided into 
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separate stages including the scope assessment stage, the risk assessment stage, and 
the virus scanning stage. In the scope assessment stage, a determination as to the 
extent of the virus scan is made. In the risk assessment stages, determinations 
about the conditions presented at the requested site are used to produce objects in 
5 the virus scanning stage. 

If it is determined by the IVDM 450b in conjunction with the scanning 
module 454, and, where necessary, the virus pattern module 456 and virus rules 
module 458, that a virus is present, a vaccine is tailored according to the ^e of 
treatment desired, the conditions, and the type of virus that is detected. As with the 
10 scanning routines and detection information, the routines in the cleaning module 
460 and the patterns or other data in the cleaning pattern module 462 are provided 
for separate access so that the routines and data necessary for the treatment can be 
separately accessed. Again, the access can be provided by conventional indexing 
and sorting techniques. Virus treatment objects are produced using the IVDM 
15 450b in conjunction with the cleaning module 460. Additionally, as with the virus 
detection objects, the treatment objects can be iteratively produced using the results 
of previous objects. 

Various remedial routines are provided by the cleaning module 460. 
Dependent upon the conditions presented at the client 300 and the type of virus 
20 detected, the remedial routines can take immediate actions such as deleting a file, 
stripping out infected portions of a file, or replacing infected portions with a benign 
portion. In addition to these actions, which are aimed at correcting infected files, 
the remedial routines can provide warnings to parties that could be affected by the 
detected virus, and could provide virus specific indications. For example, where a 
25 virus is detected within a particular type of Java applet that was downloaded to a 
client 300 within a network, the network administrator can be notified so that 
similar entities could be blocked from entering tiie network. 

Referring now to tfie event diagram of Fig. 5, a metiiod of iterative virus 
detection using tiie virus detection server 400 is shown to include an initiation 



-26- 



wo 98/41919 PCT/US98/D3796 



Stage, a scope assessment stage, a risk assessment stage, a virus scanning stage, and 
a remedial stage. 

The initiation stage is prompted by a request 505 for a virus scan. The 
request can be initiated direcUy by a cUent 300 which accesses the virus detection 

5 server 400 using conventional network communication protocols. Although the 
triggering event 502 that prompts the request 505 is typicaUy initiated directiy by 
the user of tiie client 300, tiie request can alternatively be initiated by a triggering 
event otiier tiian user prompting or initiation. This allows for regular virus 
scanning witiiout requiring user input. Additionally, a group of computers that a 

10 user might seek to manage, such as a plurality of computers residmg on a LAN, 
can be subjected to regular virus scanning without requiring user initiation and 
with minimal use of network resources. Moreover, since the virus detection server 
400 can be maintained separately from tiie stand alone client 300 or tiie computers 
300 on a local area network, tiiere is littie or no need for virus detection data 

15 maintenance on tiie part of eitiier tiie cUent 300 users or tiie LAN administrator. 
Preferably, an agent program is used to provide non-user initiated scanning 
requests. The agent program gatiiers uiformation witiiout necessarily requiring tiie 
presence or mput of tiie user and initiates a request for a virus scan whenever tiie 
gatiiered information corresponds to a predetermmed triggering event 

20 An exemplary trigg«ing event is tiie l^ing of a i»edetennmed amount of 

time since tiie most recent virus scan. Otiier triggering events include tiiose likely 
to facilitate tiie spread of viruses. These triggering events mclude attempted 
internet access, receipt or transmission of electronic mail, or downloadmg files 
over the internet Additionally, a plurahty of events in combination, such as tiie 

25 first attempted internet access after a predetermined amount of time has elapsed 
since tiie most recent virus scan, can be tiie triggering event It is understood tiiat 
various triggering events in addition to tiiose described above can be provided. 

The agent program, upon a detection or determination tiiat the triggering 
event has occurred, issues a request for a virus scan to the virus detection server 
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400. Then, the response (after validation) by the virus detection server 400 is 
"pushed" to the client 300. Conventional programmmg techniques are used for the 
agent program and conventional techniques are used to gather the relevant 
information to determine the triggering event occurrence. 
5 Preferably, where the client 300 is not a part of a local area network such as 

client 300a as shown in Fig. 1. the agent program resides at the client 300a. Where 
the client 300 communicates with the virus detection server 400 through local area 
network channels such as cUents 300b as shown in Fig. 1, an agent program can 
reside at tiie client 300b, or, preferably, can reside at a LAN server 350 (such as a 
10 gateway server, a non-gateway LAN server, or a proxy server) capable of 

monitoring network trafBc relevant to the determinations corresponding to the 
triggering event. Preferably, tiie agent program is produced using routines 
provided in the access managing module 464. The agent program is transmitted to 
the selected location (e.g. client 300a, cUent 300b, LAN server 350, proxy server) 
15 using conventional networic transmission protocols, and can be stored in tiie client 
300 memory 314 or tiie storage location appropriate to tiie selected location. 
Conventional programming languages can be used for tiie agent program. 

The request 505 for a virus scan is detected 5 10 by tiie virus detection 
server 400, and tiien it is determmed 520 wheflier tiie request is valid. The routines 
20 and rules for tiie determination of access validity are respectively provided by tiie 
access managing module 464 and rules module 466 and are described in 
connection witii tiie iterative virus detection module 450b. Briefly, tiie filtering 
module 464 identifies tiie request and accesses tiie rules in tiie rules module 466 to 
determine whetiier tiie request is valid by reference to tiie access rules. Existing 
25 accounts are typically filtered, but tiie module 464 is arranged to accept and 
aitange the origination of new accounts. 

Oncfc it is determined tiiat a vaUd request for virus scanning has been made, 
tiie scope assessment stage commences. In tiie scope assessment stage, tiie virus 
detection server 400 typically determines where a scan will be performed. Various 
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information can be determined in the scope assessment stage, such as the media to 
be scaimed, the locations (e.g. directories) to be scanned, or which group of files 
are to be scanned. A virus detection object to ascertain the scope of the virus scan 
is produced 525 by the virus detection server 400 and is then transmitted 530 to tiie 
5 client 300 using conventional network communication protocols. Preferably, the 
virus detection object prompts input by the user at tiie client 300 to procure 
information about tiie scan. One or more predetermined virus detection objects can 
be indexed and stored in memory 414 for access by tiie IVDM 450b. One example 
of a virus detection object procures information including tiie devices, memories, 
1 0 directories, and files tiiat require scanning. 

The client executes 535 tiie virus detection object in order to gatiier tiie 
relevant information. Of course, user input may be required dependent upon tiie 
requirements dictated by tiie virus detection object. The cUent 300 also transmits 
540 tiie results for receipt by tiie virus detection server 400. Preferably, tiie virus 
15 detection object includes a portion for transmitting 540 tiie results to tiie virus 
detection server 400 to obviate tiie need for continuing user input in tiie exchange 
of objects and results. Alternatively, tiie user can be prompted for simple input, 
such as clickmg a button witii tiie mouse 322 or timjugh keyboard 318 input, in 
order to cause the transmission 540. 
20 Various alternatives can be provided for tiie scope assessment stage. The 

production of a virus detection object correspondmg to flie stage is not absolutely 
required. For example, tiie IVDM 450b can retain virus detection information in 
tiie access data module 466, or elsewhere, corresponding to tiie identification of tiie 
requester. Additionally, account information corresponding to particular types of 
25 requests can be provided in tiie access data module 466. The account information 
can correspond to all of tiie computers on a LAN and provide all tiie necessary 
background mformation about tiiose computers so tiiat tiiey can be scanned witiiout 
iterative scope assessment. Alternatively, tiie information can be provided along 
witii tiie request for a virus scan, particularly where tiie client 300 includes a virus 
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detection sheU 332. Finally, the virus detection server 400 can rely upon defeult 
settings (e.g. scan the entire client 300 hard disk) and thus proceed with a virus 
scan using the defeult settings, without inquiry. 

After the necessary information is gathered, the risk assessment stage 

5 commences. In the risk assessment stage, the determined scope of scanning is 
analyzed to determine whether and which files or data could contain viruses. 
Preferably, vims detection objects are produced and transmitted to the client 300 to 
determine whether and what types of scanning will be required. Where a virus 
detection object corresponding to the scope assessment stage is provided, the 

10 results of its execution at the client 300 can be used in the production of the next 
virus detection object. Various information is ascertained in the risk assessment 
stage. Where specific targets are identified, such as specific storage media or 
directories, the virus detection object is produced 545 to determine whether and 
what ^e of scanning is required for the specified targets. For example, the virus 

15 detection object is produced 545 to determine the types of files residing in the 
specified directory (e.g. whether executable files are resident), or the type of 
storage medium or directory (e.g. whether the client or directory corresponds to a 
postal node in an electronic mail system) so that the risks presented by the 
specified targets are evaluated so that subsequent virus scanning can be tailored to 

20 the risks presented. As with other virus detection objects, ttie object includes an 
executable program (and possibly other data) specific to the task of making the 
determination. 

Specifically, where, for example, a directory is initially specified as the 
scanning domain per scope assessment, a program for accessing the file header for 
25 each file in the specified directory, comparing the file header to predetermined data 
to determine whether the file is of the type that is likely to contain a virus, and 
maintaining an identification of those files that are found to be likely virus 
candidates can be provided in the virus detection object. Various alternatives for 



-30- 



wo 98/41919 



PCT/US98/03796 



the virus detection object or objects corresponding to the risk assessment stage will 
be evident to the ordinarily skilled artisan. 

Preferably, the virus detection object is transmitted 550 to and executed 555 
by the client 300 so that results corresponding to the execution can be transmitted 

5 560 to the virus detection server 400. As with the virus detection object 

corresponding to the scope assessment stage, the virus detection object originally 
transmitted 550 to the client 300 can include the means necessary for causing the 
. transmission 560 of the results to the virus detection server 400. Preferably, in the 
risk assessment stage, the transmission 560 is automatic, requiring no user input 

10 Again, the transmissions 550, 560 between the client 300 and virus detection server 
400 will implement conventional network protocols. 

Although a single virus detection object is shown to correspond to the risk 
assessment stage, it is understood that a plurality of objects could be iteratively 
produced withm the stage. Additionally, as with the scope assessment stage, 

15 defeult settings, predetermined settings or directly provided input to the virus 

detection server 400 can be relied upon for the risk assessment stage, obviating the 
requirement for virus detection objects for both the scope and risk assessment 
stages. In that instance, the iterative production of virus detection objects 
corresponds only to the virus scanning stage. 

20 Upon completion of the risk assessment stage, the virus scanning stage 

commences. The virus detection server 400 iteratively produces a virus detection 
object or objects based upon the results of previous executions in order to scan for 
viruses. Thus, the virus detection objects can be specifically produced according to 
the desired scanning and conditions presented at the client 300. This allows 

25 eflfective virus scanning without requiring an exhaustive transmission of virus 

detection data to the client 300 to effectuate the scan. As described with reference 
to the iterative virus detection module 450a, particularly the scanning module 454, 
virus pattern module 456 and ykus rules module 458, the routines, patterns and 
rules for the detection of vhuses are provided such that they can be 
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separately accessed and thereby used to produce specific virus detection objects 
corresponding to the virus scanning stage. The produced virus detection objects 
will include executable programs according to the dictates of the information by 
previous virus detection object iterations or will be otherwise tailored for the 
S conditions presented at the client 300. 

Various scanning routines are implemented by the virus detection objects in 
the scanning stage. For example, where a signature scan of executable files is 
sought, the virus detection object includes a program for accessing each targeted 
executable file, determining \(^ether each targeted file includes a string Uiat 
10 corresponds to a virus signature firom the group of virus signatures that could be 
expected to be found in the targeted files, and retdning information about the 
targeted files that are found to include virus signatures. Signature scanning 
techniques, such as a state engine, can be used determine whether targeted files 
include virus signatures. 
1 5 One way that the amount of data to be transmitted firom the virus detection 

server 400 to the client 300 is minimized is that only those virus signatures that 
could be expected according to the gathered information about the assessed scope 
and risk fiom previous stages. For example, where the scope and risk assessment 
indicate that only .exe files in a particular directory on a particular client drive are 
20 to be scanned, virus detection objects are tailored to effect that type of scan. 

Specifically, those virus signatures \**ich could reside in .exe files and a routine 
for conducting a signature scan for the files at the noted location are provided in a 
virus detection object, the object is executed at the client 300, and the results are 
transmitted to the virus detection server 400 in the detection of viruses. 
25 Although a single virus detection object is shown to correspond to the virus 

scanning stage, it is understood that a plurality of objects could be iteratively 
produced. Thus, in addition to the tailoring offared by the scope and risk 
assessment, the iterative production of virus detection objects can be mdependently 
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tailored to minimize the amount of infonnation to be transmitted between the 
server and client and to minimize the use of computational resources. 

Various types of scanning are implemented for efQciwit iterative analysis. 
An preferred technique which allows exhaustive signature scanning without 

5 requiring a comprdiensive download of the signature data is described with 
reference to Fig. 4D above. Other scanning techniques are also provided for 
iterative virus detection. For example, techniques for Ae determination of i«^ether 
a macro includes a virus can be modularized or divided into a plurality of fimctions 
which can be performed by separate virus detection objects. To explain, in the 

1 0 detection of known and unknown viruses in macros, combinations of suspect 
instructions can be used in the determination of whether a file includes a virus. 
Specifically, a macro that includes both a first suspect instruction and a second 
suspect instruction can be determined to include an unknown (or known) virus. 
Thus, in accordance with the present invention, separate virus detection objects are 

15 provided to first detect whether and which of several targeted files include a first 
suspect instruction, and then to detemiine whether those targeted files that include 
the first suspect instruction also include the second suspect instniction to detect a 
virus. To produce a first virus detection object the IVDM 450a operates with the 
scanning module 454 and the virus rules module 458 to obtain the routines and 

20 data required for the detection of the first suspect instruction. After transmission of 
the first virus detection object fromihe virus detection server 400 to the client 300 
and execution by the client 300, identification of those files that include the first 
suspect instruction can be identified in the results transmitted to the virus detection 
server 400. Alternatively, the file identifiers can remain at the client 300 and the 

25 result could indicate which suspect instruction was identified. In either case, the 
virus detection server 400 can use the results to produce an additional virus 
detection object to determine whether the second suspect instruction is present. 

Additionally, techniques for the detection of viruses in electronic mail 
messages can be modularized or divided to provide for iterative virus detection 
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within the virus scanning stage. Preferably, an initial virus detection object 
determines vi^ether the whether any unread messages reside at the client 300 (or at 
a postal node used by the client 300). If the result of that determination indicates 
that there are unread messages, then additional virus detection objects can 
5 determine \»4iether the unread messages include attachments, decode any found 
attachments, and scan the decoded attachments to determine whethw the unread 
messages include viruses. Although a single virus detection object could be 
produced for each of the functions of determining whether there are unread 
messages, determining whether attachments are included, decoding attachments, 
10 and scanning decoded attachments, each virus detection object could alternatively 
perform more than one of the noted ftmctions. 

Still referring to Fig. 5, once the virus detection object is produced 565, it is 
transmitted 570 to the client 300 for execution 575. The results of the execution 
are transmitted 580 to the virus detection server 400 so that the results can be 
15 analyzed 585. As with the risk assessment stage, the virus detection object 
originally transmitted 570 to the client 300 preferably includes a portion for 
causing the transmission 580 of the results to the virus detection server 400 without 
requiring client 300 input by the user or otherwise. The analysis 585 includes an 
initial determination of whether additional virus detection objects are required for 
20 scanning, and, where no additional virus detection objects are required, a 
determination of whether a virus was detected. 

If, as a result of the virus scanning stage, it is determined 590 that a virus 
was detected at the client 300, then the remedial stage commences. A vaccine in 
the form of a virus treatment object is tmlored according to the type of treatment 
25 desired, the conditions presented at the client 300, and the type of virus that is 
detected. As described regarding the IVDM cleaning module 460 and cleaning 
pattern module 462, various remedial routines which can be accessed separately for 
production of the tailored virus treatment object are provided. Additionally, 
various remedial actions may be undertaken, including deleting a file, stripping out 
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infected portions of a file, or replacing infected portions with a benign portion. 
Once the virus treatment object is produced 605 it is transmitted 610 to the client 
300 so that it can be executed 615 for appropriate treatment of the virus. 
Optionally, the results of the treatment can be transmitted 620 to the virus detection 
5 server 400 so that the results can be analyzed 625. As with the virus detection 
objects, conventional networic transmission protocols are used to transmit flie 
objects to and fiom the virus detection server 400, and, although a single iteration 
is shown, a plurality of virus treatment objects can be unplemented to effectuate 
the appropriate remedy. 
1 0 Referring now to the block diagram of Fig. 6A, another embodiment of a 

virus detection server 450b is shown. The virus detection server 450b includes a 
scanning module 654, virus pattern module 656, virus rules module 658, cleamng 
module 660, cleaning pattern module 662, access managing module 664 and access 
data module 666 vs*dch are similar to the modules included with the virus detection 
15 server 450a of Fig. 4b. However, in addition to these modules, die virus detection 
server 450b includes a virus information expert system 625. The wus information 
expert system 625 is in operative communication witii the scanning module 654, 
virus rules module 658, virus pattern module 656, cleaning module 660, cleaning 
pattern module 662, access management module 664 and access data module 666. 
20 The virus information expert system 625 gather information and provided 

conditional data, applies the conditional data to predetennined knowledge or rules, 
and uses the knowledge based application of the gatiiered information to make 
determinations about the propriety of virus scanning, tiie scope and risk presented 
by the scanning targets, the selection of virus detection routines, and, where viruses 
25 are detected, the selection of treatment routines. 

Referring now to Fig. 6B, the virus information expert system 625 
comprises an inference engine 630, a virus knowledge module 632, a user interface 
634, and a conditional data module 636. The inference engine 630 is preferably a 
forward chaining type which determines results based upon a progression tiirough a 
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series of rules, preferably of the condition and corresponding action type. The 
ordinarily skUled artisan will recognize that various alternative inference engines, 
such as backward chaining type and those with fuzzy logic based reasoning, can be 
implemented. The user interfece 634 is conventional and allows users to interface 
5 with the expert system 625 to provide knovrtedge or other types of i^tes. The 
virus knowledge module 632 comprises the information and rules used in 
conjunction with the various operations of the IVDM 450b. The inference engine 
630 accesses conditional data from &e conditional data module 636, and applies 
the conditional data to the rules provided in the virus knovdedge module 632 in 
10 order to make virus scanning determinations used in tiie operation of the IVDM 
450b. Specific determinations include the determination of whether a scan is 
appropriate, the assessment of the conditions pertaining to the request for scanning, 
and the type of scanning and cleaning routines to be implemented. 

The conditional data includes factual information about scanning requests, 
15 predetermined conditions pertaining to cUents 300 or other entities associated with 
scanning requests, and, optionally, information discovered during scanning 
opoations. Additionally global information pertaining to all of the virus scanning 
performed by the IVDM 450b can be provided in the conditional data module 636 
and used in virus scanning determinations. The information pertaining to a 
20 particular account or requester can be provided by networic communication with 
the relevant party, such as a client 300 user or a network administrator. 
Additionally, information can be gathered by agent programs and provided to the 
conditional data module 636 without requiring user input. 

In the preferred embodiment, the condition and action based rules in the 
25 virus knowledge module 632 are provided in an if ... then format and are classified 
to facilitate knowledge updates. Preferred rule classes include tiiose pertaining to 
scanning interval, condition diagnosis, and remedies. The scanning interval rules 
are used in the determmation of whether scanning is to be undertaken, tiie 
diagnostic rules are used in tiie determination of whetfier viruses may be present 
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and which scanning routines are appropriate dependent upon the conditions 
present, and the remedial rules are used to determine the appropriate response to 
the detection (or lack of detection) of a virus. 

The scanning interval rules preferably include temporal and circumstantial 

5 conditions and corresponding actions. Some exemplary scanning interval rules are 
provided to illustrate the various conditions that could be determined and reacted to 
in accordance with the present invention: "if scanning has not been undertaken in 
timing interval a, then scan for viruses", "if targeted client has attempted internet 
access n times, then divide timing interval by 2", "if targeted client has attempted 

10 internet access o times, then scan for viruses", "if client has received p electronic 
mail messages with attachments, then scan for viruses", "if client has downloaded 
files from internet, then scan for viruses", "if a virus was detected at entity in 
communication with client, then scan for viruses", "if client has only 
communicated within local area network within interval b, then multiply timing 

15 interval by 2", "if previous virus scan was within c, then do not scan for viruses", 
and "if scanning has not been undertaken since time d, then scan for viruses." 

The exemplary rules provide for virus scans at regular intervals and can 
adjust the interval, in either direction, dependent upon various conditions. 
Additionally, floor and ceiling intervals (c,d) are provided such that scannmg is 

20 mandatory within certam mtervals and such that unduly repetitive scanning is not 
undertaken. The ordinarily skilled artisan will recognize the various conditions 
and actions that can be applied in the determination of whether a virus scan is to be 
undertaken.- 

The conditional data module 636 provides the information applied to the 
25 rules in the knowledge module 632 by the inference engine 630. In the preferred 
embodiment, the conditions are initially provided in the conditional data module 
636 and are updated by communication firom a client, client agent, or other entity 
responsible for providing the mformation to the virus detection server 400. The 
conditions are periodically applied to the rules, and, under the appropriate 
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conditions, a "request" for a virus scan is produced by the virus information expert 
system 625. As with the other IVDM 450a embodiment, the request can be 
received and validated using the access management module 664 and access data 
module 666. Various alternatives can be provided for the mamtenance of 

5 conditional data and for the receipt and validation of requests. Specifically, the 
conditional data can be maintained and provided from resources other than the 
rVDM 450b. For example, a client 300, an agent program, or a network 
administrator could gather the appropriate information and transmit the 
information to the virus detection server 400. Further, information pertaming to a 

10 network could be provided in the form of a virus scanning request and the expert 
system 625 used to deteraiine which clients 300 or other entities require scanning. 

The diagnostic rules provided in the virus knowledge module 632 are used 
to make determinations analogous to those provided in the scope and risk 
assessment stages described with reference to the event diagram of Fig. 5. The 

15 diagnostic rules are ^plied to conditional data to determine, for a client, a group of 
clients, or other scannable entities corresponding to a virus scanning request, 
actions such as where scanning is to be performed and \s^at type of scanning is to 
be performed. As with the scanning interval rules, the inference engine 630 applies 
the information in the conditional data module 636 to the rules in the virus 

20 knowledge module 632. The conclusions dictate the application of appropriate 
virus scanning routines, provided in the scanning module 654, using appropriate 
patterns and virus scanning rules. 

The diagnostic rules preferably include circumstantial conditions and 
corresponding actions. The following exemplary diagnostic rules illustrate the 

25 various basic conditions that could be determined and reacted to in accordance 
with the present invention: 

"if the scanning scope is indicated by the request for virus scanmng, scan 
according to the request"; 
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"if the scanning scope if not indicated by the request, determine whether the 

client includes writable media"; 

"if client does not include writable media, then do not perform vims scan"; 
"if a related scan detected Virus X, then scan client for Virus X"; 
5 "if the client includes a hard disk, then scan accordmg to the conditions 

specific to the hard disk": 

"if.exe files are present, then perfonn file vuns signature scan", 
"if.com files are present, then perform file virus signature scan", 
"if application data files are present, then scan for macro viruses", 
10 "if the cUent is a postal node, then scan all unread messages for 

attachments", 

"if the client has received electronic mail, scan unencoded portions 
diereor,and 

"if client includes a Java applet execution engine, then scan for hostile Java 
15 applets"; 

"if the client includes other writable media, the determine the conditions 
specific to the writable media and scan the writable media." 

The exemplary rules determine the basic scope of the scan based upon the 
conditions prevailing at the client. The scan can also be tailored to tiie conditions 
20 tiiat prompted tiie request for a virus scan. For example, where tiie scan is 

triggered by voluminous receipt of electronic mail, only electronic maU messages 
might be scanned in lieu of the entire hard disk, particularly where tiie hard disk 
has been recently scanned. 

Upon determination of a valid scan request and an assessment of tiie 
25 conditions presented at tiie cUent 300 by tiie virus information expert system 625, 
tiie identified targets are scanned for viruses. Preferably, tiie scanning is 
undertaken by tiie IVDM 450b using tiie scanning module 654, in communication 
witii tiie virus pattern module 656 and virus rules module 658 using iteratively 
produced virus detection objects using the techniques described witii reference to 
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the IVDM 450a of Fig. 4B above. For example, where the virus information expert 
system 625 applies the conditions presented at a client 300 to the rules in the virus 
knowledge module 632 and it is determined that an entire hard disk is to be 
scanned for file type (e.g. exe, .com) viruses, then the IVDM 450b produces virus 
5 detection objects that are used to iterativcly determine whether the cUent 300 hard 
disk includes any ffle type viruses. Preferably, the virus signature portion 
techniques described with reference to Fig. 4D are used to determine whether any 
file type viruses reside at the client 300. Although iterative detection and 
corresponding techniques are preferred, if is understood that the virus mfonnation 
10 expert system 625 can prompt any type of scanning. For example, the virus 
information expert system 625 can prompt tiie IVDM 450b to download 
con^)rehensive signature scanning and corresponding detection signatures to tiie 
client 300, if desired. The iiidexing provided in tiie scanning, virus pattern and 
virus rules modules is used to ensure tiiat tiie downloaded routines correspond to 
15 tiie desired type of detection. 

If a virus is detected as a result of tiie virus scan, tiien tiie remedial stage 
commences and tiie routines provided by tiie cleaning module 660 are 
implemented, along witii tiie cleaning pattern module 662, if necessary, to provide 
a remedy for tiie detected conditions. Preferably, virus treatment objects are 
20 produced to provide tiie remedy as described witii reference to tiie IVDM 450a 
above. Optionally, tiie virus information expert system 625 provides knowledge 
based determinations regarding tiie types of remedial routines to be implemented. 
For example, tiie virus information e^ert system 625 determines whetiier files will 
be corrected to maintam tiieir integrity, deleted entirely, or stripped of any viral 
25 portions. Additionally, determinations are made regarding tiie notification 
provided to tiie client 300 user, related users, network administrator, or otiier 
parties. Furthermore, otiier remedial actions, such as requesting a transfer 
prevention for certain classes of files corresponding to tiie type of virus detected 
can be implemented. Specifically, tiie IVDM 450b, at tiie request of tiie expert 
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system 625 can send an email to a network administrator indicating that a certain 
type of file included a virus and was transmitted into the network, or can 
communicate directly with a network computer, such as a server including a proxy 
server, to provide reconfiguration instructions to block the entry of the types of 
5 files in v^iiich a virus was detected. 

Referring now to the schematic diagram of Fig. 7, an exemplary network 
communication system 700 includes a local area network (LAN) with cUents 300c, 
a gateway server 7 10 and an administrative server 750. The gateway server 710 
operates an entrance to another network, here the WAN, and the administrative 
10 server 725 is a server, within the LAN, that performs administrative fimctions. As 
with Fig. 1, the virus detection server 400 resides on the WAN, and a client server 
relationship can be established between the virus detection server and the cUents 
300c or, altemadvely, between the virus detection server 400 and the gateway 
server 710 or administrative server 725 (with the gateway server 710 or 
15 administrative server 725 being the client). The connections can be established 
using conventional media and conventional network transmission protocols. 

Referring now to the block diagram of Fig. 8A, an embodiment of an 
administrative server 725 in accord with the present invention comprises a CPU 
802, memory 804, data storage device 806, I/O ports 808 and a network link 810. 
20 The CPU 802 is a conventional processor, the memory 804 is conventional 

addressable memory (such as RAM), and the VO ports 808 and network link 810 
are conventional. The CPU 802, memory 804, I/O ports 808 (and correspondmg 
devices), and network interface 810 are coupled to a bus 814 in conventional 
feshion. The CPU 802 performs functions under tiie guidance and control provided 
25 by instructions received fcom memory 804, tiie fimctions including 

communications through network media 812 usmg tiie network interface 810. The 
memory 804 also mcludes a proxy server 820. The proxy server 804 acts on behalf 
of other servers or clients in mformational exchanges. Altiiough various proxy 
804 types can be provided, a preferred proxy server 804 gatiiers Internet 



server 
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requests from network computers such as cUents 300c, communicates the requests 
to Internet servers, and receives responses from the Internet servers for 
■ communication witii the requester (such as the clients 300c). 

Referring now to the block diagram of Fig. 8B, the memory 804 is shown 

5 to further include an embodiment of a netwo A diagnosis and maintenance 

application 825 in accordance with the present invention. The network diagnosis 
and maintenance application 825 can reside separate from the proxy server 804 or 
can be bundled with die proxy server 804. The network diagnoas and maintenance 
application 825 comprises a virus information expert system 830, a diagnostic data 

10 module 850 and a maintenance requesting module 875. The application 825 also 
includes optional additional expert systems 840, 845, such as a network response 
expert system and an iqjplication software expert system. The application 825 
includes routines for gathering information pertaining to the network, producing 
and maintaining diagnostic data sing the gatiiered information, making 

15 determinations concerning network conditions by applying die diagnostic data to 
predetermined knowledge, and generating requests for network maintenance based 
upon die determinations. The networic diagnosis and maintoumce plication 825 
is preferably computer software, but can also be hardware or firmware. 

Generally, die application 825 operates as follows. The diagnostic data 

20 module 850 includes routines for gathering information pertaming to tiie network 
and producing diagnostic data from the gatiiered information. The diagnostic data 
module 850 is in communication witii die expert systems 830, 840, 845 and tiius 
facilitates their access of tiie diagnostic data. Preferably, each expert system 830, 
840, 845 includes an inference engine, a knowledge module, and an interface. The 

25 interface is a conventional type interface, such as a menu driven one, whidi allows 
users to communicate witii die system. The knowledge module provides a 
knowledge base, typically in tiie form of information and rules which are specific 
to tiie task to be perfonned. The inference engine is a conventional type such as a 
forward chaining type. The inference engine accesses conditional data in tfie 
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diagnostic data module 850 and applies the conditional data to the information and 
rules in the knowledge module to make deteminations about conditions on the 
network. The expert systems make specific diagnostic determinations pertaming to 
their field of expertise. The expert systems are also in communication with the 
5 maintenance requesting module 875, and provide their diagnostic determinations to 
the module 875, which produces requests for maintenance. TypicaUy, requests are 
made to resources outside of the local area network, such as a vuus detection 
server 400, to provide the mamtenance. 

An exemplary expert system is the virus information expert system 830. 
10 This system 830 analyzes network activity to conditional determinations including 
vAiea virus scanning is to be performed, where virus scanning is to be performed, 
the gaieral type of vuus scanning to be performed, and the preferred remedies 
where viruses are detected. These determinations are provided to the maintenance 
requesting module 875 which communicates a request for virus scanning to the 
1 5 virus detection server 400 and provides the virus detection server with the 

conditional determinations. Other expert systems 840, 845 could be provided in 
accordance with the present invention. For example, a network response exptit 
system 840 could monitor network activity to ensure response time adequacy, 
could make determinations as to whetiier outside resources should be sought to 
20 solve any inadequacies, such as by lowering tiie burden on local resources. 
Additionally, an application software expert system 845 could detCTmine tiie 
conditions for providing software updates. Again, tiie determination tiiat an update 
is required could prompt a request for tiie update firom remote resources. Altiiough 
exemplary additional expert systems, such as a network response expert system 
25 840 and an application software expert system 845 are disclosed, tiie artisan wiU 
recogni» vjuious alternative expert systems. 

Referring again to tiie virus information expert system 830, tiie virus 
knowledge module 834 has various rule classes including fliose for scanning 
interval and condition diagnosis. The scanning mterval niles are used to determine 
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\niiether scanning is to be undertaken, and include temporal and circumstantial 
conditions and corresponding actions. The diagnostic rules also include 
circumstantial conditions and correspcmding actions and are used to make 
detaminations analogous to those provided in the scope (e.g. -wbich media, 

5 directories, files are to be scanned and risk assessment (e.g. which files or data in 
the defined scope might contain viruses) stages of virus treatment. Exemplary 
scanning interval and condition diagnosis rule sets are described widi reference to 
the IVDM 450b resident expert system 625. Additionally, as with that systwn, 
rules pertaining to the selection of remedies upon the detection of a virus can be 

10 provided. 

The diagnostic data module 850 is in communication with the proxy server 
820 and is coupled to the local network transmission medium 812 to gather 
information about the network. Preferably, the information includes which clients 
300c have attempted internet access, what types of operations and protocols were 

15 used in communications between each cUent 300c and other entities including 

those outside the network. This information is readily ascertainable by analysis of 
the data packets traversing the networic medium or by communication directed 
fiom, for example, the proxy server 820 to the diagnostic data module 850. For 
example, an HTTP proxy server arranged to handle all HTTP requests by the 

20 clients 300c could merely identify the client and corresponding request to the 

diagnostic data module, and an FTP proxy server arranged to handle file transfers 
could indicate which clients 300c obtained file downloads using tiie relevant 
protocol as well as an identity of tiie source of the transferred file. In addition to 
the gatiiered infonnation, background information about each client 300c, such as 

25 that concemmg its CPU and storage media (e.g. hard disk) is provided in the 

di^ostic data module 850. Furthermore, related information such as the timing 
of the most recent virus scan for each client 300c is provided. The diagnostic data 
which is applied by the expert system to the knowledge base comprises all of this 
infonnation, which is conventionally stored in the diagnostic data module 850. Of 
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course, other information is provided dependent upon the types of additional expert 
systems 840, 845 which are provided. 

The expert systems 830, 840, 845 access the diagnostic data and make 
determinations concerning network conditions by applying the diagnostic data to 
5 the predetennined knowledge. SpecificaUy, with the virus information expert 
system 830, the inference engine 832 applies the diagnostic data such as that 
relating to last scan, electronic mail receipt, file downloading, attempted mtemet 
. access to the scanning interval rules provided in the virus knowledge module 834 
in order to determine when a virus scan should be requested and applies the 
10 diagnostic data such as that relating to storage media and types of files downloaded 
in order to determine the extent of any requested virus scan. 

The expert systems 830, 840, 845 are also in communication with tiie 
mamtenance requesting module 875. Thus, once a determination is made tiiat 
network maintenance is required, tiie systems 830, 840, 845 prompt tiie module 
15 875 to generate a corresponding request. Specifically, in conjunction witii tixe 
virus information expert system 830, tiie mamtenance requesting module 875 
directs a request for virus scanning to tiie virus detection server 400. In a simple 
case, tiie request pertams to a single client 300c for a comprehensive scan. 
However, all or selected clients 300c, storage devices, or otiier entities residing on 
20 tiie network could be scanned. To make a particular request for scannmg, 

including which media, directories or files are to be scanned, what types of files are 
to be scanned, and what remedies are sought, tiie maintenance requesting module 
875 includes an virus detection and treatment interface 880 for providing 
customized communication witii tiie virus detection server 400. 
25 The initial request, determination of request vaUdity, and subsequent 

scanning stage are described witii reference to tiie virus detection server 400. 
Altiiough iterative virus detection techniques are preferably arranged and 
performed by a WAN resident virus detection server 400, it is understood tiiat any 
resources using any scanning and treatinent protocols can be implemented at the 
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request of the network diagnosis and treatment application 825. For example, the 
request for virus scanning by the application 825 can initiate the downloading of 
comprehensive virus signatures and/or scanning routines, or the performance of a 
scan upon the targeted cUent 300c by a LAN resident server using conventional 

5 signature scanning techniques. 

Once the virus scanning has been performed, the determination as to 
whether a virus was detected, and the remedial result can be communicated to the 
network diagnosis and maintenance application 825, preferably using the treatment 
interface 880. As with the remedial stage described above, the remedy can include 

10 file deleting, file stripping, file amending, and various types of party notification, 
nie results can be used to update the diagnostic data module 850 so that fiiture 
scans can account for the determinations of previous scans. Additionally, various 
network elements, uicluding the proxy server 820, can be notified or reconfigured 
as a result of the scan. Specifically, if a particular file corresponding to a particular 

15 transfer protocol was found to contain a virus, the appropriate proxy server can be 
reconfigured to block passage of that file type in the fiiture. Additionally, using the 
source identification provided in the diagnostic data module 850, fiiture file 
transfers from the source of the infected fde could be blocked, the source could be 
notified, or the clients 300c on the network could be notified about the source of 

20 the infected file. 

Altiiough the present invention has been described with reference to certain 
preferred embodiments, tiiose skilled in tiie art will recognize that various 
modifications may be provided. For example, altiiough separate modules for 
access managing, scanning and cleaning are shown and described, it is understood 

25 that tiie various piwesses may be integrated mto common modules or subdivided 
mto additional modules which perform equivalent fimctions for receiving virus 
scanning requests, validating tiiem, diagnosing and detecting viruses, and treating 
viruses. Additionally, altiiough certain iterations in tiie detection and treattnent of 
viruses are described, it is understood tiiat tiie correspondence between each 
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iteration and the function or functions perfonned in each iteration can vary. Tl 
and other variations upon and modifications to the described embodiments are 
provided for by the present invention which is limited only by the following 
claims. 
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CLAIMS 

What is claimed is: 

1 . For use in a system wherein a client and a server can be connected 
to communicate with each other, a method for detecting viruses, the method 

5 comprising: 

transmitting a first virus detection object from the server to the 

client; 

receiving a result based upon the execution of the first virus 
detection object; 

10 producing a second virus detection object based upon a result of the 

execution of the first virus detection object; transmitting the second virus 
detection object from the server to the client; 

receiving a result based upon the execution of the second virus 
detection object; and 

1 5 detemiining whether a virus is present at the client based upon the 

Insult of the execution of the second virus detection object 

2. The method of claun 1 , fiirther comprismg: 

if it is determined that a virus is present at the client, tailoring a 
20 remedy for the virus based upon at least one of the result of the execution of 

the first virus detection object and the resuh of the execution of the second 
virus detection object. 

3. The method of claim 2, wherein the step of tailoring a remedy 
25 comprises: 

producing a virus treatment object and transmitting the virus 
treatment object firom the server to the client; and 

executing the virus treatment object at the client. 
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4. The method of claim 1 , further comprising: 
determining whether a virus scan is to be performed prior to the step of 
transmitting a first virus detection object fix>m the server to the client. 

5 5. The method of claim 4, i^dierein the step of determming whether a 

virus scan is to be performed comprises detecting a request for a virus scan and 
determining the validity of the virus scan request 

6. The method of claun 5, wherein the request is prompted by a 
10 triggering event. 

7. The method of claim 6, wherein the triggering event is the first 
attempted internet access by the client after a predetermined time interval from a 
previous virus scan. 

15 

8. The method of claim 1 , wherein the first virus detection object and 
the second virus detection object correspond to a virus scanning stage. 

9. The method of claim 8, wherein the first virus detection object is 
20 used to determine whether a first vuus signature portion is present in targeted files 

and the second virus detection object is used to determme whether a second virus 
signature portion is present in those targeted files that include the first virus string 
portion. 

25 1 0. For use in a system wherein a client and a server can be connected 

to communicate with each other, an apparatus for detecting viruses, the apparatus 
comprising: 

means for transmitting a first virus detection object from the server 
to the client; 
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means for receiving a result based upon the execution of the first 
virus detection object; 

means for producing a second virus detection object based upon a 
result of the execution of the first virus detection object; 
5 means for transmitting the second virus detection object fix>m the 

server to the client; 

means for receivmg a result based upon the execution of the second 
virus detection object; and 

means for determining whether a virus is present at the client based 
1 0 upon the result of the execution of the second virus detection object. 

11. The apparatus of claim 1 0, further comprising: 

means for tailoring a remedy for a detected virus based upon at least 
one of the result of the execution of the first virus detection object and the 
1 5 result of the execution of the second virus detection object. 

12. The apparatus of claim 10, fiuiher comprisii^: 
means for detecting a request for a virus scan; and 

means for determining the validity of the wus scan request 

20 

13. The apparatus of claim 12, wherein the request is prompted by a 
triggering event. 

14. The £q)paratus of claim 13, wherein the triggering event is the first 
25 attempted internet access by the client after a predetermined time interval fi:om a 

previous virus scan. 

15. The apparatus of cldm 10, wherein the first virus detection object 
and the second virus detection object correspond to a virus scanning stage. 
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16. The apparatus of claim 15, v^erein the first virus detection object is 
used to determine whether a first virus signature portion is present in targeted files 
and the second virus detection object is used to determine whether a second virus 
signature portion is present in those targeted files that include the first vims strmg 

S portion. 

17. A virus detection server for detecting viruses, the virus detection 

server comprising: 

a processor; and 

JO a memory, in communication with the processor, the memory 

providing instructions which, when executed by the processor, cause the 
processor to transmit a first virus detection object from the virus detection 
server to a client; receive a result based upon the execution of the first virus 
detection object; produce a second virus detection object based upon a 

15 result of the execution of the furst virus detection object; transmit the 

second virus detection object firom the server to the client; receive a result 
based upon the execution of the second virus detection object; and 
determine whether a vmas is present at the client based upon the resixlt of 
the execution of the second virus detection object. 

20 

1 8. The virus detection server of claim 1 7, wherein the first virus 
detection object is used to determine whether a first virus signature portion is 
present in targeted files and the second virus detection object is used to determine 
whether a second virus signature portion is present in those targeted files that 

25 include the first virus string portion. 

19. A network diagnosis and maintenance apparatus for diagnosing and 
maintaining a network, the apparatus comprising: 



-51- 



wo 98/41919 PCT/US98/03796 



a diagnostic data module, for providing diagnostic data pertaining to 
the network; 

an expert system, in communication with the diagnostic data 
module, for providing knowledge for the diagnosis and maintenance of the 
5 network, for applying the diagnostic data to the knowledge, and for making 

determinations based upon the application of the diagnostic data to the 
knowledge; and 

a maintenance requesting module, in communication with the expert 
system, for requesting network maintenance based upon the determinations 
10 made by the expert system. 

20. The network diagnosis and maintenance apparatus of claim 1 9 
vAierein the expert system is a virus information expert system which comprises: 
a virus knowledge module, for providing virus scanning rules, the 
J 5 virus scannmg rules mcluding interval rules for determining 

v^ether a virus scan should be requested and diagnostic 
rules for determining the scope and type of virus scanning; 

and 

an inference engine, in communication with the virus knowledge 
20 module, for accessing the diagnostic data, for applying the 

diagnostic data to the virus scanning rules, and for making 
virus scaiming determinations based upon the application of 
the diagnostic data to the rules. 

25 21 . The network diagnosis and mamtenance apparatus of claim 20 

wherein the apparatus resides within a local area network, and the maintenance 
requesting module directs a request for virus scanning to a virus detection server 
that resides outside of the local area network. 
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22. For use with a network diagnosis and maintenance apparatus for 
diagnosing and maintaining a network, a method for diagnosing and maintaining 
networks, the method comprising: 

providing diagnostic data pertaining to the network; 
5 providing knowledge for the diagnosis and maintenance of the 

network; 

applying the diagnostic data to the knowledge; 
making determinations based upon the application of the diagnostic 
data to the knowledge; and 
JO requesting network maintenance based upon the determinations, 

23. The method of claim 22, further comprising: 

providing vuiis scanning rules, the virus scanning rules including 
interval rules for determining whether a virus scan should be requested and 
1 5 diagnostic rules for determining the scope of virus scannmg; 

applying the diagnostic data to the virus scannmg rules; and 
making virus scanning determinations based upon the application of 
the diagnostic data to the rules. 

20 24. The method of claim 23 , wherein the request for virus scanning is 

directed to a virus detection server based upon the step of making virus scanning 
determinations. 

25. A virus detection server capable of communicating with a client 
25 over a netwprk, the vmis detection server comprising: 

an access managing module, for receiving requests for virus 
scanning, the request conespondmg to a client to be scanned for viruses; 

a vmis scanning module, for providing routines used in the 
detection of viruses; and 
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a virus information expert system, in commimication with the 
access managing module and the virus scanning module, for providmg 
conditional data pertaining to clients to be scanned for viruses; for 
providing virus scanning rules including interval rules for determining 
whether a virus scan should be requested and diagnostic rules for 
determining the scope and type of virus scanning; for applying the 
conditional data to the virus scanning rules; and for making virus scamung 
determinations based upon the application of the conditional data to tiie 
rules. 

26. The virus detection server of claim 25, further comprising: 
a virus cleaning module, in communication with the virus 

information expert system, for providing routines used in the treatment of 
viruses. 

27. The virus detection server of claim 26, further comprising: 
means for selecting routines for the detection and treatment of 

viruses based iq)on the virus scanning determinations made by the virus 
information expert system and transmitting tiie selected routines to the 
client. 

28. For use with a virus detection server capable of communicating with 
a client over a network, a metiiod for detecting viruses, the metiiod comprising: 

receiving requests for virus scanning, the request corresponding to a 
client to be scaimed for vuuses; 

providing a plurality routmes used in the detection of viruses; 

providing conditional data pertaining to clients to be scaimed for 
viruses; 
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providing virus scanning rules including interval rules for 
determining whether a virus scan should be requested and diagnostic rules 
for determining the scope and type of virus scanning; 

applying the conditional data to the virus scanning rules; and 
makmg virus scanning determinations based upon the application of 
the diagnostic data to the rules. 

29. The method of claim 28, further comprising providmg a plurality of 
routines used in the treatment of viruses. 

30. The method of claim 29, further comprising: 

selecting routines for the detection and treatment of viruses based 
upon he step of making virus scanning determinations; and 
transmitting the selected routines to the client. 
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This International Searching Authority found multiple (groups of) 
inventions in this international application, as follows: 

1. Claims: 1-18 

network server iterativly prepares virus detection objects 
and sends them to client for execution 



2. Claims: 19-30 

upon request expert system is used to evaluate network 
diagnostic data and to determine network maintenance 
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Annex to supplemental sheet b 



The Internationai Searching Authority considers that the present application contains 2 
inventions. This observation is based on the following reasons: 

The prior art has been identified as WO93/25024 (D1 ). 

This document describes (see column 5. line 23 - column 6, line 15) a host system with a 
security device which scans its file system for virus characteristics and destroys detected 
virae using information previously downloaded from a remote database at a networit 
monitoring host: if this destwction is unsuccessful further aid is requested from the network 
monitoring host to detect and destroy the vims. It thus discloses the technical features of a 
server, supplying virus detecting and destroying maintenance Information requested and 
executed by a ciient. 

Since these technical features are known, they don't make a contribution over the prior art 
and therefore are not "special technical features* (STF) as defined In mle 13.2 PCT. They 
cannot be considered to represent the common general inventive concept for the groups of 
inventions described in claims 1- 18 and 18- 30. The requirements of unity of invention are 
fullfilted only if for these groups of inventions another common concept, which has to be 
inventive, can be found. It is the opinion of this ISA that such concept is not present. 
Grounds: 

1. From the comparison of the first invention and the disclosure of D1, the following technical 
features of the first Invention (claims 1- 18) can be seen to make contribution over D1 and 
therefore are considered to be "special technical features" (Rule 13.2 PCT) of the first 
invention: . 4k 

- receiving results of the execuUon of the first and second virus detection object, solving me 
objectiviy detennined problem of supplying infonnatlon necessary for tailoring the virus 
detection objects iteratlvly and the remedy for the virus. 

2. For the same reasoning, from comparison of claims 1 9- 30 and this same prior art (01), 
the "potential" STF of the second invention are: 

- an expert system evaluating diagnostic data to reply for a maintenance request, soMng the 
objecthr problem of adapting the maintenance scheme to changing conditions. 

The above analysis shows that the STF of the 2 groups of inventions are not the same. A 
comparison of the objective problems related to the different groups of the inventions, all 
seen In the fight of the description and drawings of the application, shows that they are all 
different and have no corresponding technical effect Consequently the STF of the different 
inventions do not correspond and the requirements of Unity of invention (Rule 13.1 & 13.2 
POT) are not fullfilled. 
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